Internet Pilot Project for the Deployment of X.500 Directory Information in
Support of X.400 Routing
Status of this Memo
This document is an Internet Draft. Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its Areas, and its Working Groups.
Note that other groups may also distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months. Internet
Drafts may be updated, replaced, or obsoleted by other documents at any time.
It is not appropriate to use Internet Drafts as reference material or to cite
them other than as a "working draft" or "work in progress."
To learn the current status of any Internet-Drafts, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on
nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au.
Abstract
The Internet R&D X.400 community (i.e. GO-MHS) currently lacks a distributed
mechanism providing dynamic update and management of message routing
information. The IETF MHS-DS Working Group has specified an approach for
X.400 Message Handling Systems to perform message routing using OSI Directory
Services. The MHS-DS approach has been successfully tested in a number of
local environments. This INTERNET--DRAFT describes a proposed Internet Pilot
Project that seeks to prove the MHS-DS approach on a larger global scale.
The results of this pilot will then be used to draw recommendations for
a global scale deployment.
INTERNET--DRAFT Introducing Project Long Bud June 14, 1993
1 Background
An MHS community gathers several administrative MHS domains among which
agreements for cooperative routing exist: the GO-MHS community is the set
of MTA's taking care of X.400 mail operations on the Internet
[Hagens et al. 93]. A number of routing problems are preventing the
present Internet R&D X.400 service from expanding its number of
participating message transfer agents to a global scale. The two most
critical problems are:
* The present mechanism of maintaining and distributing static, centralized
MTA routing tables has become too labor intensive. Further practical
growth can not be achieved using the current method without sacrificing
accuracy and reliability.
* X.400 routes are not consistent when accessed by different MTAs scattered
across the globe. The existing MTA routing tables are too static. They do
not accommodate the variety of routing options which apply when the X.400
service is expanded to a global scale.
It is commonly accepted that a distributed mechanism providing for dynamic
updating and management of X.400 routing information is highly desirable. For
this to occur, it is essential that X.500-based support of X.400 routing be
established. The purpose of the Long Bud pilot project is to prove that the
concepts and procedures developed within the MHS-DS working group are viable
in an operational service environment and that they can be expanded to a
global scale in a straightforward fashion.
2 Definition of project LONG BUD
2.1 Project Goals
Project Long Bud has the following basic goals:
* Gather operational experience of the defined framework for X.500 support of
MTA routing, as defined by the IETF MHS-DS Working Group [Kille 92]. This
should facilitate and expedite the global deployment of X.500 usage with
this particular scope by providing experimental feedback into the current
work before any operational deployment is started.
Alvestrand et al. Expires: November 25, 1993 [Page 1]
INTERNET--DRAFT Introducing Project Long Bud June 14, 1993
* Actively investigate migration of the existing operational R&D X.400
service from a routing method based upon distribution of centrally
maintained static tables, as specified in [RFC 1465], to a method based
instead upon X.500. This goal is comprised of two subgoals:
-- Deploy X.400 MTA's which are directly capable of reading routing
information from the X.500 Directory, in compliance with the
specifications of the MHS-DS Working Group. This type of MTA
is called a directory-capable MTA.
-- Deploy tools which read routing information from the X.500 Directory
and use it to generate static routing tables for MTA's which are not
directory-capable.
Long Bud is focused on the use of X.500 Directory. It does not address the
problem of communities using proprietary directories mechanisms (e.g. PC
mail systems on a private LAN which need to route messages to the Internet
X.400 community). However, the second subgoal above may be used as an
interim solution to provide such communities, following an appropriate data
format conversion method, with global Internet X.400 routing information.
Still, use of static tables may also be considered by sites where
operational conditions (e.g. very low mail traffic outside the community)
do not require external access to a dynamic infrastructure.
The principal goal of the first phase of Project Long Bud is to deploy a small
number of directory-capable MTA's operated by members of the MHS- DS Working
Group and GO-MHS community. These MTA's must be capable of using information
in the X.500 directory to route messages to all other members of the project as well as to the existing GO-MHS community. This initial set of MTA's should be
operational by July 1993.
Prerequisites for reaching the goal are:
* The X.500 DIT must be populated with enough routing information to allow
the participating MTA's to route messages to each other and to the
existing GO-MHS community.
* The X.500 DSA's holding the routing information must operate at a quality
of service that is acceptable for an operational R&D X.400 service.
* A sufficient number of MTA managers must be willing to participate in
Project Long Bud.
Alvestrand et al. Expires: November 25, 1993 [Page 2]
INTERNET--DRAFT Introducing Project Long Bud June 14, 1993
Note that in the first phase, default routes will be established in the DIT
such that messages addressed to destinations outside of the Long Bud community
will be routed to designated MTA's in the GO-MHS community.
This will allow for full connectivity between the Long Bud community and
the GO-MHS community.
In the second phase of Project Long Bud, a greater number of MTA's should be
added to the experiment. Now it is quite possible that the set of destinations
reached in Project Long Bud may be different from that which can be convenientlyreached using the GO-MHS table-based approach, and it is therefore important to make tools that can take information from the DIT and produce routing tables foruse in GO-MHS and vice versa.
2.2 General Approach
No large scale resources have been committed to this project. Yet, expedient
deployment is desirable. Therefore, the pilot project needs to be focused and
relatively short-lived. The general approach for satisfying these requirements
includes:
* Use as many existing MHS-DS tools as possible. Also, continue to track the
progress of tools being developed by project members and facilitate their
deployment as soon as they are ready.
* Coordinate efforts with existing COSINE/GO-MHS service.
2.3 Tools Needed
To facilitate widespread deployment of MHS-DS routing technology and to foster
interworking between directory-capable MTA's and MTA's which are not
directory-capable, the following tools need to be developed:
PutRoutes : this tool will accept routing information, specified in the
standard syntax used by the GO-MHS community (see [RFC 1465]), and
it will create and/or update X.500 directory entries which convey
the same information.
GetRoutes : this tool will read X.400 routing information from the X.500
directory and generate static routing information from it. The syntax
of the static information generated will conform to the syntax defined
by the GO-MHS community.
Alvestrand et al. Expires: November 25, 1993 [Page 3]
INTERNET--DRAFT Introducing Project Long Bud June 14, 1993
DisplayRoute : this tool will accept two parameters as input: the X.500
distinguished name of an MTA, and an X.400 O/R name. It will display the
possible routes which may be taken in order to deliver a message from the
specified MTA to the specified X.400 destination.
These tools should be implemented using Internet standard API's such as LDAP so
that they can be ported easily to multiple platforms. Other standard APIs (e.g.
X/Open XDS) will be used when sufficiently deployed in the Internet community.
2.4 Time Frame
Long Bud, Phase 1 : July 1993
Phase 1 of the project should be operational by July 1993 so that it can be
demonstrated at the IETF meeting in Amsterdam. The DisplayRoute tool
should be available in this time frame too so that it can be used as a
demonstration device.
PutRoutes, GetRoutes : June 1993
These tools will facilitate interworking between directory-capable
MTA's and MTA's which are not directory-capable. Availability of
these tools is, therefore, very important, but they are not absolutely
needed for initial deployment of Phase 1, nor are they absolutely
needed as demonstration devices at the IETF meeting in Amsterdam.
Nevertheless, the estimated completion date for these tools, if achieved,
will allow them to be incorporated into existing GO-MHS procedures
(i.e. the AUSSIE tools developped by the COSINE-MHS Service) and
will also allow them to be demonstrated in Amsterdam.
3 Participation Guide
The existing operational R&D X.400 service, the GO-MHS service, uses the method
described hereafter to distribute and manage X.400 routing information.
A group of MTA's is organized into a routing community. The community keeps its
routing information up to date by assigning the following responsibilities
to each MTA manager:
1. Determining the routing information for his/her MTA.
2. Expressing this routing information using the formal syntax defined by and
for the community.
Alvestrand et al. Expires: November 25, 1993 [Page 4]
INTERNET--DRAFT Introducing Project Long Bud June 14, 1993
3. Sending the routing information to a central e-mail coordination center
(EMCC) that validates this data against all of the other routing
information received from all of the other MTA's in the community.
After verification is complete, the EMCC releases the data to the
general community.
4. Receiving the verified routing information via electronic mail or some
other means. Note that the verified routing information is distributed
by the EMCC on an unscheduled basis, as soon as information needs to be
updated.
5. Converting the routing information, if necessary, into the format required
by his/her local MTA and integrating it with any other local routing
information needed.
6. Updating his/her MTA configuration with the new, integrated routing
information. Note that this step is a local decision and, as such, is not
synchronized with the other MTA's in the community.
The purpose of Project Long Bud is to allow a manager to operate an MTA without
having to perform ANY manual steps when another MTA manager adds new or changes
existing routing information. This will facilitate efficient, dynamic, and
manageable interconnection of very large communities of MTA's. It will allow
the Internet X.400 community to overcome the limitations in scalability which it
currently is encountering.
3.1 Prerequisites for participati on
The prerequisites for joining Project Long Bud are made of different steps
organized as follows:
Step 1 : participants in the pilot must have a good knowledge of the
IETF MHS-DS Workin Group activities and documents:
1. Participants must join the MHS-DS distribution list:
RFC-822: mhs-ds@mercury.udev.cdc.com
X.400: PN=mhs-ds; OU=mercury; OU=OSS;
OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US
Alvestrand et al. Expires: November 25, 1993 [Page 5]
INTERNET--DRAFT Introducing Project Long Bud June 14, 1993
Requests to join the MHS-DS distribution list may be sent to the
following email address:
RFC-822: mhs-ds-request@mercury.udev.cdc.com
X.400: PN=mhs-ds-request; OU=mercury; OU=OSS;
OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US
2. Participants must retrieve and become familiar with all relavent tools
and documents stored on the Project Long Bud anonymous FTP server
